The present invention relates to electronic engine control systems, and more particularly to systems and methods for the calibration of such engine controlled systems.
Since the late 1980""s, most internal combustion engines have included an electronic control module, or ECM. The ECM controls the electronic components of the engine, such as fuel injectors, egr valve, air intake, etc. In the early years of the ECM, the module utilized specific unchangeable programs for controlling the operation of the engine.
In recent years, the ECMs have become field-programmable. This feature enables product enhancements to be made in existing ECMs at a greatly reduced cost. In a typical application, one generic control module can be programmed for many different applications, e.g., different engine ratings or different engine applications. These changes can be made without any alterations to the physical configuration of the module.
The field-programmable ECM is the last element in a chain of calibration and application software development. This chain is depicted in FIG. 1. At the beginning of the chain is a development tool 10, which is typically a personal computer. A designer uses the development tool to create application software and application-specific calibration information for an ECM 20. Each ECM includes a memory for storing a number of programs 20a-20z for control of the ECM and control of the various electronic engine components. The applications and calibration information, or sub-files, are usually developed in conjunction with the creation of a new or modified engine or fuel system ratings. For example, in the case of new engine torque requirements, an engine developer creates new torque curve data and, through the development tool 10, ultimately programs the ECM 20 with the new data. In the typical case, the development tool uses a configuration file to determine how to change data in the ECM 20. The configuration file contains information about each item in the ECM that can be monitored or calibrated and provides information that defines the compatibility situation for these items in the calibration.
Once an engine developer or software engineer creates the sub-files, the data is uploaded to a main frame computer 12 in an engine manufacturing plant or design facility. At the main frame computer 12, the sub-files generated from a number of development tools 10 are integrated and authorization levels are set for specific sub-files.
Ultimately, the sub-files initially generated at the development tool 10 are distributed via communication lines 13 to other various locations, such as engineering, service, manufacturing and end-customer sites. Each of these independent sites has a service computer 14 that receives the new downloaded information. Synthesis and calibration of similar software in the service computer 14 performs a number of data checks to verify the file information. The calibration assembler within the service computer then attaches calibration-loading instructions for an associated service/calibration tool 16. Typically, this information is downloaded to the service tool 16 through an RS232 connection 15 with the service computer 14.
The service tool 16 is the final link to updating the calibration information for the ECM 20. In a typical circumstance, the service/calibration tool 16 communicates with the ECM 20 by way of a data link 17. Typically, this data link uses an SAE J1708 interface standard and a unique handshake protocol.
The service/calibration tool 16 includes code or software programs 16a stored in memory. This software can be resident within the tool and activated/loaded when needed, or it can be dynamically loaded as required from a PC. This component of the service tool includes code for all of the update and calibration functions accomplished by the tool 16. For instance, the code can include software for updating engine ignition data, cruise control attributes, etc. or for providing software control enhancements to the ECM. Since every ECM does not require every enhancement or calibratable function, the service tool 16 only dynamically loads calibration code from the module 16a that is necessary under the circumstances. This dynamic loading feature can be accomplished automatically when the service tool 16 is linked to the ECM, based upon the calibratable ECM data. Alternatively, the technician can selectively load the code, depending upon selected calibrations to be made.
As a further alternative, rather than dynamically loading the code, the subject code can be resident within the ECM, but inactive. In this case, the dynamic loading function performed by the service tool entails sending a signal to the ECM to xe2x80x9cactivatexe2x80x9d the specific code or calibration information.
While the calibration chain shown in FIG. 1 has significantly improved engine design and development, there is always room for improvement. One problem arises where new engine models or variations of engine models are developed and introduced to the marketplace. Typically each new engine requires a new engine calibration. In prior systems, the service tool 16 must have complete compatibility with the particular ECM 20. In the case of a new engine, the new ECM is often unrecognizable to the existing service tool 16, which ultimately prevents the technician from calibrating or upgrading the engine control.
With these prior systems, the first action taken by the service tool when it interfaces with an ECM is to read an application identifier stored within the ECM. This application ID carries information as to the calibration of the particular enginexe2x80x94e.g., engine type, etc. Next, the tool reads from the ECM information relating to the version level of the calibration. If the specific service tool supports the particular version level of the subject ECM, the calibration can be changed and updated. However, if the version level in the ECM is different than that supported by the tool, the tool is inhibited from accessing the calibration at all. Thus, with these prior systems, absolute compatibility is required between the service tool and the engine and ECM to be calibrated or updated.
This problem can arise where the new ECM incorporates a small change in an existing calibration feature. In addition, difficulties occur when the new ECM has a feature added to the standard calibration.
In either case, the existing service tool can be prevented from working with the calibration for the new ECM. What is needed is a service tool and ECM relationship that is more akin to physical maintenance of an engine. In other words, an engine mechanic can be faced with a brand new engine design and still be able to use standard tools to service virtually every feature of the engine. The only aspect of the new engine that may not be directly serviceable by the mechanic is a brand new, unfamiliar feature. Even in that instance, there may be certain aspects of the new physical engine feature that can be adjusted or maintained by the mechanic.
This same circumstance does not inhere in the software end of the engine. The limitations that presently exist between the service tool and the ECM do not allow the electronic calibration world to emulate the physical component world. There is therefor a need for a service tool and ECM interface protocol that overcomes the compatibility barriers present with systems of the prior art.
These problems with the engine evaluation, upgrade or calibration chain are addressed by aspects of the present invention that emulate the physical world. More particularly, the invention resides in a recognition that features of an engine control module can be divided into specific features and general features. These features may be manipulated, upgraded, read/written or calibrated by the service tool. For example, a general feature may be the engine cruise control, while the specific feature corresponds to a particular type of cruise control system.
In accordance with one aspect of the invention, each calibratable feature maintained in the ECM is assigned a globally unique identifier (GUID). The ECM can maintain a table in a memory, which can be a non-volatile memory such as a flash memory. The table can contain a list of features associated with that ECM, as identified by GUID. These features may be subject to modification or re-calibration by the service tool, or can simply be features that are read or written by the tool, depending upon the application. The table can relate each specific GUID to a general GUID, if one exists for the particular feature. In the cruise control example, a GUID of 150 can be assigned to a specific cruise control system. That GUID is stored in the ECM non-volatile memory. In addition, a GUID of 100 can be assigned to the general cruise control feature, of which the specific cruise control is a member. The relationship between the specific GUID 150 and the general GUID 100 can be retained in the ECM non-volatile memory.
In a further feature of the invention, the service/calibration tool queries the ECM through a standard communication link. Specifically, the calibration tool reads the contents of the ECM non-volatile memory to extract the GUIDs for the calibratable/upgradable features of the ECM. Where a specific GUID has a corresponding general GUID, it is also read. The calibration tool then compares the list of GUIDs to determine whether the tool includes calibration or upgrade software corresponding to the ECM calibratable features. This comparison is achieved in the preferred embodiment by comparing the list of GUIDs obtained from the ECM to a corresponding list within the calibration tool. In a most preferred embodiment, this list comparison proceeds from the more specific feature to the most general. Where GUIDs match, the calibration tool will dynamically load or access calibration/upgrade software associated with the particular GUID, or calibratable/upgradable feature.
In the nominal case, each specific GUID will correspond to dynamically loaded code within the calibration tool or inactivated code within the ECM itself. However, in some instances, a specific GUID extracted from the ECM will not have a corresponding GUID in the calibration tool. In this case, the calibration tool then turns to the general GUID to which the specific GUID is associated. If such inheritance relationship exists, the calibration tool will dynamically load the calibration software associated with the general calibratable/upgradable feature. In the cruise control example, the general calibratable feature may include calibration data for maximum speed or set/resume activation features that are common to all cruise controls.
In some case, the calibration tool will not have a GUID that corresponds to a particular specific or a general GUID in the ECM. Such a circumstance may arise when a brand new feature has been added to an ECM and the calibration tool has not been upgraded to recognize that new feature. Thus, when no GUID match is found within the calibration tool, no calibration of that new feature in the ECM occurs.
One benefit of the present invention is that it allows the software world of the field-programmable ECM to emulate the physical world when it comes to calibration or upgrade of an ECM. The invention avoids the characteristic problem of the prior art that a particular calibratable/upgradable feature of an ECM would be entirely ignored because it included a new aspect not yet recognized by the calibration tool.
Another benefit of the invention is that it allows older or non-upgraded calibration tools to retain some functionality, even as new generations of ECMs are developed. The present invention allows those calibration tools to perform calibrations of general features of the ECM, even when those features have experienced first, second and third generation improvements.
Other benefits and certain objects of the invention will become apparent upon consideration of the following written description and associated figures.